Transmission Control Protocol (TCP) is a protocol in the well-known TCP/IP (Internet Protocol) suite of communication protocols (see [RFC 793] for a full description of the TCP protocol). TCP provides a connection-orientated, reliable, byte stream service and was originally designed for wired networks that have very low error rates.
TCP operates a window based flow control mechanism that limits the amount of unacknowledged data that the sender transmits. This limit is based on a minimum of the congestion window (cwnd) and an advertised window (awnd). The congestion window is controlled by the sender of TCP data and is based on the well known slow start and congestion avoidance mechanisms. Slow start acts to slowly increase the amount of unacknowledged data in the system at the start of a TCP flow and congestion avoidance halves the amount of unacknowledged data in the system when a missing packet is detected and then slowly increases the unacknowledged data back again to its normal flow level. The awnd is controlled based on the receiver's ability to process more data. The initial value of ‘awnd’ is controlled by parameters configured in the TCP protocol stack.
As mentioned above, TCP is designed for low error rate networks. Therefore any packet losses that occur in TCP-based commmunication networks are considered as being due to network congestion and are therefore followed by a reduction in ‘cwnd’ and, consequently, in the data rate of the sender, as mentioned above.
However, this is not appropriate to wireless networks that are inherently high error rate systems. Therefore, the 3rd Generation Partnership Project (3GPP) standard provides Automatic Repeat Request (ARQ) functionality, known as Radio Link Control (RLC) (as described in the 3GPP technical specification 3GPP TS 25.322) that allows data packets to be re-transmitted that have been subjected to error as a result of transmission over the air-interface. The reliability of delivering data packets is maintained by a use of RLC acknowledgement messages (ACKs) that are sent by the RLC receiving entity back to the RLC transmitting entity, in response to a predefined trigger. The trigger could be based on, for example, a timer, on receiving a certain number of received packets, or detecting that a packet has been lost. In this manner, lost or corrupted data segments or data packets may be indicated to the transmitter, and these lost or corrupted data segments or data packets may be re-sent. Note also that in later versions of 3GPP (which support HSDPA and E-DCH) an additional retransmission scheme is provided by hybrid automatic request (HARQ) functionality located in the layer-1 (L1) and medium access control (MAC) layers of the well-known OSI protocol.
However, the use of ARQ (and HARQ) schemes result in data packets arriving out of order. Hence, the data packets have to be buffered before they can be passed on for TCP processing. The use of buffering introduces increased delay and this can result in increased RTT (Round Trip Time).
Many wireless data systems have very large air interface throughputs, but also have a high latency, such as the long-term evolution (LTE) being defined by the 3GPP Standards group and the competing WiMax communication standard. Thus, significant problems arise due to the operation of TCP over typical wireless systems. For example, due to the high latency it takes a relatively long time for TCP rates to exploit the high air-interface throughputs and whilst slow start is running the communication link is therefore under utilised. This is particularly an issue when multiple TCP connections are opened for each relatively small object, e.g. when a mobile user is web browsing.
The typical ‘awnd’ value used in most personal computer (PC) TCP stacks is low (of the order of 8192 bytes). This means that the communication link in high latency wireless systems can never be fully utilised unless the ‘awnd’ is modified. Typically, the ‘awnd’ value should be set to the bandwidth delay product of the link. However this only provides a means of allowing the air-interface to be fully exploited for TCP data flows in the downlink (DL) direction, namely from the network to the end-user. In the uplink (UL), namely from the mobile (or fixed) user to the network, the ‘awnd’ is specified by the server in the network and clearly there is no way this can be altered in a similar fashion. Therefore, with increasingly high UL rates being achievable, the UL TCP rate will, in many circumstances, be limited by the server ‘awnd’ not the prevailing air-interface conditions.
An additional problem associated with simply increasing the awnd in high latency wireless systems is that any lost data packets due to congestion in the core network causes the DL TCP rate to be badly affected and, due to the high associated latency, a long time to recover. As mentioned previously it is beneficial to use very large awnd values to fully utilise the high data rate high delay air-interface communication link (for example, an ‘awnd’ value of the order of ‘100000’). When a lost data packet occurs the ‘cwnd’ is reduced to half this value. This halved value is typically not enough to fully utilise the communication link, and hence the observed throughput is reduced.
Thus simply increasing the ‘awnd’ is not an acceptable solution to TCP performance in high latency wireless systems.
Referring now to FIG. 1, a known mechanism for TCP data flow 100 is illustrated. The TCP data flow 100 is arranged between a personal computer (PC) 105, a user equipment (UE) 10, such as a mobile phone, a radio access network (RAN) 115 and a communication server 120. In the known mechanism, TCP ACKs are sent over the air interface. As mentioned previously, a typical TCP network may additionally employ both radio link control (RLC) layer communication 130 and hybrid automatic repeat reQuest (HARQ) 135 error correction over the wireless network between the UE 110 and the RAN 115.
The inventor has both recognised and appreciated that the TCP acknowledgement messages (TCP ACKs) sent over the air-interface are largely unnecessary and are simply a waste of valuable air-interface resources. This is because the underlying RLC and HARQ retransmission schemes (which also employ ACK messages themselves) will ensure that losses in the air interface are corrected, thereby rendering the retransmission functionality of TCP redundant and thus the TCP ACKs do not need to be sent over the air interface. As shown in FIG. 1, three levels of data flow control/re-transmission functionality exist for TCP data packets, which is considered as suboptimal.
Referring now to FIG. 2, a TCP architecture 200 is illustrated that mitigates some of the problems associated with employing TCP over wireless systems. The TCP data flow is arranged between a personal computer (PC) 205, a user equipment (UE) 210, such as a mobile phone, a radio access network (RAN) 215 and a communication server 220. The TCP network architecture employs both radio link control (RLC) layer communication 230 and hybrid automatic repeat reQuest (HARQ) 235 error correction over the wireless network between the UE 210 and the RAN 215.
Notably, this architecture removes the end-to-end TCP connection, by incorporating logic in both the UE 210 and the RAN 215 that performs a TCP proxy function. The result of this is that there is a necessity for some form of flow control at the TCP proxy to exist, to ensure that RLC buffers do not overflow.
Because the end-to-end TCP functionality is removed it is now possible for the IP and TCP header to be completely removed at the proxy and only the underlying data portion of the packet, plus any headers associated with RLC and MAC, is transmitted over the Uu interface. The receiving proxy will then add the TCP header appropriate to the state of the TCP connection that exists at this end of the system.
To clarify the functionality employed in the TCP network architecture 200 in FIG. 2, an example data flow is considered below. If a file transfer protocol (FTP) download of a very large file is initiated, then if the TCP proxy logic at the RAN 215 has no flow control functionality then potentially the whole FTP file will need to be stored in the RNC RLC buffers within the RAN 215. Thus, some method of flow control is needed at the TCP proxy that allows the ‘awnd’ to be controlled based on the available buffer occupancy at the transmit RLC entity. This is dealt with, in a limited fashion, in known arrangements where a single measure of buffer occupancy is used to determine the ‘awnd’ value signalled.
A potential problem with this scenario, in known architectures, is that a RLC Move Receiving Window (MRW) command or reset may occur whilst maintaining the connection. A RLC MRW command indicates that the transmitting entity has given up sending a RLC protocol data unit (PDU) and that the receiver must move its window forward so that it skips all RLC PDUs that make up an RLC-SDU. In this circumstance, TCP flow control would previously have provided a final means with which a re-transmission of the lost data segment can occur. Without an overlying TCP protocol, no such retransmission will occur. Furthermore, with totally separate TCP connections at the UE and network ends, it is difficult to provide an additional retransmission scheme to overcome this problem.
Additionally, in flows without end-to-end TCP functionality, potential problems can occur when the UE changes cell, due to the fact that different (i.e. non-synchronised) TCP sessions are occurring at the PC side and the network side.
Referring now to FIG. 3, a data flow control protocol architecture 300 using a known 3-way handshake process is illustrated. The 3-way handshakes 310 are sent through the RAN protocol stack as normal i.e. using RLC/MAC/L1. It is noteworthy that this is different from the case for the full non-end-to-end conventional functionality, as described in FIG. 2. In FIG. 2, two separate 3-way handshakes would occur between the user PC and the UE side and proxy and the server and the network side proxy, where no 3-way handshake would occur over the air interface.
As the 3-way handshake is employed end-to-end, it is now possible to employ TCP proxies at either side of the air interface that are, in effect, ‘synchronised’. Hence, although the TCP protocol does not run over the air interface portion of the communication link, it appears from the server and client point of view that the connection is indeed end-to-end.
Hence, an improved mechanism to address the problem of TCP data flow, particularly over a cellular wireless communication network, would be advantageous.